1. Field of the Invention
The present invention relates generally to distributed data processing environments and, more particularly, to development environments and methodologies providing improved support for “remoting” technologies, such as RPC, CORBA, DCOM, SOAP, and the like.
2. Description of the Background Art
Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions, collectively referred to as a “computer program,” direct the operation of the computer. Expectedly, the computer must understand the instructions which it receives before it may undertake the specified activity.
Owing to their digital nature, computers essentially only understand “machine code,” i.e., the low-level, minute instructions for performing specific tasks—the sequence of ones and zeros that are interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring human language so that humans can get computers to perform specific tasks. While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programming languages. The most widely used programming languages are the “high-level” languages, such as C or Pascal. These languages allow data structures and algorithms to be expressed in a style of writing that is easily read and understood by fellow programmers.
A program called a “compiler” translates these instructions into the requisite machine language. In the context of this translation, the program written in the high-level language is called the “source code” or source program. The ultimate output of the compiler is an intermediate module or “object module,” which includes instructions for execution by a target processor. In the context of Borland's Turbo Pascal and Object Pascal, the intermediate module is a Pascal “unit” (e.g., a .TPU file). Although an object module includes code for instructing the operation of a computer, the object module itself is not usually in a form that may be directly executed by a computer. Instead, it must undergo a “linking” operation before the final executable program is created.
Linking may be thought of as the general process of combining or linking together one or more compiled object modules or units to create an executable program. This task usually falls to a program called a “linker.” In typical operation, a linker receives, either from the user or from an integrated compiler, a list of modules desired to be included in the link operation. The linker scans the object modules from the object and library files specified. After resolving interconnecting references as needed, the linker constructs an executable image by organizing the object code from the modules of the program in a format understood by the operating system program loader. The end result of linking is executable code (typically an .EXE file) that, after testing and quality assurance, is passed to the user with appropriate installation and usage instructions.
“Visual” development environments, such as Borland's Delphi™, are the preferred application development environments for quickly creating production applications. Such environments are characterized by an integrated development environment (IDE) providing a form painter, a property getter/setter manager (“inspector”), a project manager, a tool palette (with objects which the user can drag and drop on forms), an editor, a compiler, and a linker. In general operation, the user “paints” objects on one or more forms, using the form painter. Attributes and properties of the objects on the forms can be modified using the property manager or inspector. In conjunction with this operation, the user attaches or associates program code with particular objects on screen (e.g., button object); the editor is used to edit program code which has been attached to particular objects.
Notwithstanding the improved productivity afforded by visual rapid application development environments, classic “desktop” applications are relatively costly to deploy. This is due partly to the issues of installing and configuring the application, and partly to the issues of communicating between the client and the server. Accordingly, there has been ever-increasing interest in distributed application technology, such as “thin” browser-based or Web-based clients. This is not because distributed applications offer a richer user experience, but instead because such applications eliminate the high costs of deploying functionality to a user's desktop.
Early distributed applications employed specialized communication protocols, such as RPC (Remote Procedure Call), CORBA (Common Object Request Broker Architecture), and DCOM (Microsoft Distributed Component Object Model), to enable program components or objects to communicate with one another regardless of what programming language they are written in or what operating system they are running on. For example, a feature-rich Windows client may use DCOM to communicate with the server and invoke remote objects. Configuring such applications to work properly in a large network is a daunting task, however. Using RPC-type protocols over the Internet also represents a security problem, as firewalls and proxy servers normally block this kind of traffic. All told, most IT professionals would rather put up with the limited functionality of browser-based applications than face the task of running DCOM-based or CORBA-based applications on their networks.
In an effort to address the problem posed by complex communication protocols, programmers have more recently turned to standard Internet protocols, such as HTTP (Hypertext Transport Protocol). For example, SOAP (Simple Object Access Protocol) is a popular way to make remote method calls to classes and objects that exist on a remote server. SOAP relies on the popular XML protocol to define the format of the information and then adds the necessary HTTP headers to send it. XML (Extensible Markup Language) is itself a basic format for representing data on a “Web services” platform. By specifying a standard way to encode parameters and return values in XML and standard ways to pass them over some common network protocols like HTTP, SOAP provides a way for applications to communicate with each other over the Internet in a manner that is independent of platform. This enables the creation of various “Web services”—that is, applications or components that are self-contained, self-describing modular applications that can be published, located, and invoked across the Internet. Web services perform functions that can range from simple requests (e.g., stock quotes) to complicated business processes (e.g., credit card transactions). Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service.
From the perspective of the underlying application development environments, the many existing and emerging remote procedure/method calling standards that exist today present a problem in how the various remote services are actually “bound” to an application under development, so that those services may be invoked at runtime. In particular, at the level of the development environment used to create applications, the static language binding employed for each technology (protocol) is specific, and therefore limited, to its respective technology. Here, existing “remoting” technologies require design time generation of code or type descriptions specific to both that remoting technology and the specific remote programming interface being used. This leads to proxy stub generation (i.e., static binding), such as occurs with CORBA. Although CORBA allows some degree of dynamic binding, CORBA adopts an approach that results in loss of run-time type checking. It would be more advantageous if the run-time environment could instead generate such proxies dynamically, and do so in a manner that preserves run-time type checking.
There is a need for a development environment that supports remoting technology that does not require proxy stub generation, yet supports strong runtime type checking. Further, such a development environment should be flexible as to which wire protocol and packet format are employed. The present invention fulfills this and other needs.